IBIS Macromodel Task Group Meeting date: 09 January 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan * Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the meeting scheduled for January 30th will not be held because most attendees will be at DesignCon. - Mike asked if he could briefly discuss some questions regarding BIRD147 and the parser contract for IBIS 7.0 (Quality task group). ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Randy: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD147 (Back-channel Support) related parser checking - Discussion: Mike L. shared a draft list of BIRD-by-BIRD requirements for the parser development for IBIS 7.0. It contained a table of the five new AMI Reserved Parameters for BIRD147. The quality group was seeking input on certain parser requirements: BCI_Protocol: - Can the value be null (empty). - Do we need to prohibit "IBIS" from appearing at the beginning of the name? BCI_Training_UI and BCI_Message_Interval_UI: - Are additional checks on the values needed, perhaps related to Ignore_Bits? Walter said he felt no checks related to Ignore_Bits were required. He said the BCI_Training_UI and BCI_Message_Interval_UI need only be tested for > 0. (Note: the BIRD does state that BCI_Training_UI should be at least twice the value of BCI_Message_Interval_UI). Walter said he didn't think it was necessary to look for and reject "IBIS" at the start of a BCI_Protocol name. Mike said that if we intended to reserve protocol names beginning with "IBIS" for IBIS Open Forum approved protocols, then we should currently reject any protocol name starting with "IBIS" because there are as yet no officially approved protocols. Walter and Radek noted that the actual process for getting a protocol approved had not been defined. Radek said anyone could go to the IBIS Open Forum to get approval for a particular protocol. Walter noted that it might be done with a BIRD process, but this had not been decided. Mike observed that if the approval process did not require a BIRD or some other process that tied it to a version of the IBIS spec, then we could not check for it in the parser. The group was unsure about whether a null value for BCI_Protocol was valid. Mike L. said they would continue to review the issues in the quality task group. New BIRD draft: Figure 29 Corrections [subsequently submitted as BIRD193] - Arpad: [sharing his BIRD draft emailed to ATM prior to the meeting] - The figure relates to [Circuit Call] and [Node Declarations] for instantiating [External Circuit]s. - Highlights: - Figure 29 and associated text contained certain forward looking statements and examples that were never supported (explicit pad connections and one-to-many mappings between pins and pads). - BIRD189 will now fill in some of those holes, but not always in a way consistent with the forward looking statements (e.g. BIRD189 maintains a strict one-to-one mapping between pin and pad). - BIRD189 can coexist with legacy package model syntax. However, BIRD189 explicitly prohibits use with [External Circuit]s and [Node Declarations]. - Changes made in this BIRD remove the forward looking statements and make Figure 29 compatible with BIRD189 without any need to explicitly mention BIRD189. - Remove any text and references based on explicit die pad names, because we only support implicit die pad names based on the one-to-one mapping with pins. - Remove explicit die pad names from the examples. - In the figure, remove explicit die pad names and replace them with implicit names. Remove the one pin to two pads and one pad to two pins connections shown in the figure. - Last sentence of pg. 142, remove the word "new". - It's clear that we mean new models using this keyword, but we don't want to use "new" and create the impression that the term "new" refers to BIRD189 models, and we certainly don't want to go into defining what "new" stands for. - Discussion: Walter and Radek noted their approval of this proposal. Walter said he would support it going into 7.0. Arpad agreed and said he felt it should go into the same IBIS version as BIRD189 because it clarifies the examples relative to BIRD189. Bob noted that the proposal did not involve a syntax change, and he also recommended it be submitted to the Open Forum. Mike noted that items 2 and 3 in the Requirements section might really be considered implementation notes for item 1. Curtis noted that the first paragraph of the Proposed Changes section was not text to be included in the spec. Mike and Bob agreed and suggested that first paragraph should be moved to the Background Information section. Arpad agreed with these changes and said he would make the changes and submit the resulting draft to the Open Forum. BIRD189: Aggressor_Only graphic - Discussion: The group reviewed the Aggressor_only example graphic Mike L. emailed to the Interconnect group on January 5, 2018. Arpad noted that the figure was beautiful but only illustrated the most basic case. Arpad asked if a second example should be added that illustrated the "problem case" of a pin appearing multiple times as Aggressor_only but never as a victim. Mike asked Arpad if he could clone the original example and produce the case he wanted to illustrate. Arpad took the AR to do that. Bob noted that the example needed a legend to explain various symbols. Mike agreed. - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to submit his Figure 29 cleanup proposal to the Open Forum as a BIRD. AR: Mike L. to add a legend to his Aggressor_Only graphic. AR: Arpad to take Mike's new version and clone it to create an example with a pin that appears multiple times as Aggressor_only but never as a victim. ------------- Next meeting: 16 January 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives